home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Almathera Ten Pack 2: CDPD 1
/
Almathera Ten on Ten - Disc 2: CDPD 1.iso
/
pd
/
176-200
/
188
/
null
/
null.doc
< prev
next >
Wrap
Text File
|
1995-03-13
|
4KB
|
96 lines
***************************************************************************
*
* null.doc 20 Nov 88 Gunnar Nordmark
*
***************************************************************************
What is null:?
Tt's a new animal that you will be glad to put in your private ZOO,
(also known as the L: directory).
"Oh no, not another silly handler!" you cry, but read on!
In the very good article by Matt Dillon, AMIGALINE#D1, that I've included
in this distribution, the problem is fully explained.
I suggests that you take a look at the file amigaline-D1 before reading
further.
As Matt explains, the NIL: device is not a "real" device. In fact it is no
device at all in the physical sense. It is just an Amiga-DOS convention
that says: If you have a process-identifier for a device, and that identifier
is just a null pointer, then that "identifier" referrs to the NIL: device.
Did you get that? I'm not surprised if you didn't, because it *is* strange.
I'll try to explain:
Every normal dos-device is a process that have an own private message-port
that is used as a comunication link between AmigaDOS and the device.
Since you must know the address of the message port of a device in order
to comunicate with it, it is a natural decision that that address also is
used as the identifier of the device.
AmigaDOS has a function called DeviceProc() that finds the address for you.
If you say port=DeviceProc("RAM:") you get the address of the message prot
of the RAM: device.
Now the strange part:
If you try port=DeviceProc("NIL:") and then sends packets to that port
you'll crash the machine instantly.
Why?
Because NIL: has *no* message-port at all.
When you have a NULL-pointer as identifier for a handler, the identifier
referrs to the NIL: device.
The *only* reason I can think of for this lack of generality, is efficiency.
You save time, becase you don't have to comunicate with a device.
You save memory, because you don't have to start a new process named NIL:.
But unfortunately this has a lot of drawbacks. Most of them are deadly.
The reason is that AmigaDOS does *not* allways check for the NIL: oddity.
Sometimes it thinks that the NULL-pointer (the NIL: identifier) is a
valid message port and merilly sends messages to it. Poof!
The solution is a new dos-device called "null:".
This is a real dos-device that has has its own message port. It just doesn't
do anything useful. It behaves exactly as NIL: i.e. you can write to it,
and read from it (then you get EOF).
The great thing about null: is that you can say
extern APTR DeviceProc();
proc->pr_ConsoleTask = DeviceProc("null:");
and you'll be able to close the console. (see amigaline-D1)
Any process can open null: as many times as it like.
And it doesn't matter if you say
Open("null:" MODE_OLDFILE);
Open("null:*" MODE_NEWFILE);
Open("null:@#$@!!" MODE_OLDFILE);
Open("null:foo.bar" MODE_OLDFILE);
everything works.
To install null: just append the included mountlist to DEVS:MountList
Copy null-handler to your L: directory and say Mount null:
I have used it for half a year now with no problems at all. I have a
written my own version of AmiCron that uses null: as pr_ConsoleTask.
That means I now have a cron-deamon that doesn't requires a window
to run!
I wan't to thank Steve Drew who wrote the aux-handler that was posted
to the net last year. I've "stolen" all the code from that handler. :-)
I hope you don't mind Steve.
- Gunnar
Gunnar Nordmark
Nora strand 5
S-182 34 DANDERYD
SWEDEN
gno@stacken.kth.se
stacken.kth.se!gno@uunet.uu.net (if the above doesn't work)
gno@SESTAK.BITNET